As digital storage technology and computer networks have advanced, efforts to ensure that digital content is made available for use only by authorized recipients have also progressed. One approach for providing security for digital content information is to distribute the information in encrypted form, and then to distribute necessary decryption information in the form of keys to only legitimate users. Unfortunately, unscrupulous legitimate users can share distributed decryption keys with unauthorized recipients, so there has been an increasing trend toward preventing anonymous sharing by requiring the recipient hardware to identify itself to the distributor of secured digital information as belonging to a particular user. The distributor may be the original vendor of secured digital information, or another party that handles the various security tasks (such as computing and communication) for the vendor.
For example, U.S. Pat. No. 4,658,093 to Hellman discloses a system in which a manufacturer of “base units” (specific hardware instances of user devices that perform computations) assigns a random key to be stored by each particular base unit. When a user wants to use a software package, the user's base unit generates a random number and communicates it to the software manufacturer. The manufacturer generates an authenticator response that is a cryptographic function of the particular base unit's key, the requested software, the number of authorized times the software may be used, and the random number generated by the base unit. The manufacturer then electronically delivers the authenticator response to the user's base unit, which uses the same cryptographic function to generate a check value. (The RSA cryptographic function is used by Hellman; it is described in U.S. Pat. No. 4,405,829 to Rivest et al., which is hereby incorporated by reference.) If the check value and the authenticator response match, the base unit accepts the authenticator response as valid and accordingly increments the number of times that delivered software may be used. The base unit verifies the message from the manufacturer using a digital signature and a hash of the manufacturer's message.
Digital signatures are known in the art and generate a single-bit yes/no answer to the question “Is this message authentic?”. A hash is generally the output of a mathematical function that maps values from a large domain into a smaller range, is one-way in that it is computationally infeasible to find any input which maps to any pre-specified output, and is collision-free in that it is computationally infeasible to find any two distinct inputs which map to the same output. Such hashing functions are well known in the art. Unfortunately, the bidirectional communication that the Hellman system requires is not always available due to the distribution method employed or practical due to the sheer number of base units in the field. Also, the Hellman system requires an authorization and billing unit to maintain a memory of serial numbers and secret keys used to determine a base unit's secret key from knowledge of the base unit's public serial number.
U.S. Pat. No. 6,105,137 to Graunke et al. describes a similar system for authenticating and verifying the integrity of software modules. U.S. Pat. No. 6,138,236 to Mirov et al. extends this general approach to authenticating firmware programmed in a boot PROM and then using that trusted program code to authenticate a subsequent set of program code. The Mirov et al. system appends a digital signature to a self-extracting executable distribution file, and the distributed software is decrypted using a published public RSA decryption key. A comparison of decrypted hash values deems the self-extracting executable distribution file secure and free from accidental or intentional corruption if successful, or rejects and deletes the file if the comparison fails.
U.S. Pat. No. 6,341,373 to Shaw describes another secure data upgrading method that enables only selected portions of program code to be replaced. Shaw also requires the client device to transmit identification information regarding itself to a remote server before receiving updates from the server.
Commonly-owned U.S. Pat. No. 5,343,527 to Moore, U.S. Pat. No. 5,978,482 to Dwork et al., U.S. Pat. No. 6,038,316 to Dwork et al., and U.S. Ser. No. 09/894,035 by Baentsch et al. are hereby incorporated by reference. Moore teaches a method for providing a reuser of a software component from a reuse library with an indication of whether the software component is authentic and valid, or whether it has been tampered with by some unauthorized entity. Baentsch et al. teach a method of going from a first piece of program code to a second piece of program code (e.g. a software update) by combining the first piece of program code with a difference program code. The various program codes are signed by software providers' private keys and verified as authentic by use of a corresponding public key.
Tamper resistant software is becoming increasingly important because movies, music, text, applications, and databases are now being distributed in digital form with copy protection features. Software pirates might attempt to defeat these copy protection features simply by patching the software used in the player hardware; that is, by presenting a bogus software update to the player such that the player then makes all content accessible whether properly authorized to do so or not. Most companies in the industry rely on digital signatures to check the authenticity of a piece of software. This is not a foolproof approach, however, as the check can be disabled by patching a single instruction in player software.
Digital signets present a better solution to this problem than digital signatures. Digital signets are as difficult to forge as digital signatures, but instead of giving a single yes/no output like a digital signature, they produce an arbitrary sequence of bits K that is correct if and only if the hash of the received message is properly related to the signet.
The Dwork et al. patents cited above (one is a divisional of the other) describe digital signet based systems for protecting digital information where the logic behind extricating decryption keys for accessing the protected information is openly known and operates on an authorization number generated in response to a user number. The user number uniquely identifies and is valuable to the user, so that the user would be unwilling to disclose it to public view. User numbers could include credit card numbers, phone numbers, central processing unit ID numbers, or other numbers having personal sensitivity to the user. Thus, the user is reluctant to share keys or decrypted content with others for fear that the user number would be divulged and that the misbehaving user would be easily identified.
The hash value of a software program has proven to be a particularly good “user number”. Modifications to a software program, such as those made by hackers trying to defeat a content protection scheme, cause its computed hash value to change. Therefore, content protection can be improved when the decryption keys used in a content protection scheme are successfully extricated and used only if the software program is provably intact and unmodified.
This is the typical prior art signet calculation: K=g1hg2a mod M where K is an output sequence of bits, g1 and g2 are public numbers stored with the transmitted digital message itself, h is the hash of the message, and a is the digital signet. M is the public modulus under which this calculation is performed; in other words, K is the remainder after dividing the product g1hg2a by M. M is usually a prime number, but does not have to be. The output K is the basis for comparison used to guarantee the authenticity and integrity of the message, which may comprise a software update.
While the prior art in this field describes worthy accomplishments, there exists a need for further improvements to address unsolved needs. For example, how can the value of K, which determines if access to protected information should be allowed, be shielded from attack by those who seek to pirate it and the information it protects? If no verifying transmissions from individual recipients are feasible, how can the software being executed by the recipients be legitimately updated in the field? Any modification to the software running on a user device will generally cause its hash to change, and the subsequently computed K value will no longer be correct. Replacing user hardware is generally infeasible, and transmission of new device keys to potentially millions of users also presents readily apparent problems.